王敏：重庆农商行信用卡核心系统建设及回迁实践

文 / 重庆农村商业银行副行长  王敏

在社会生产力高速发展，社会需求高度分化的今天，企业要想拥有持久旺盛的生命力，离不开成熟先进的科技应用体系和面对精细化需求的快速适应能力。与新兴的互联网企业不同的是，银行因为信息化时间比较早，通常面临着沉重的历史技术包袱，这成为数字化转型道路上一道难以跨越的障碍。与此同时，重庆农村商业银行也深知数字化转型的必要性和紧迫性，提出了“科技兴行”战略方针，迎难而上，主动推进信息系统架构革新，以求建设符合新时代金融发展趋势，自主可控，灵活应变的科技支撑平台，助力业务健康发展，推动金融产品持续创新。

建设背景

在金融业大力发展建设各类IT基础设施的背景下，着眼到信息系统本身，使用老旧技术架构的各类银行业重要系统面对如今敏捷迭代的开发实践，精细化的服务治理，灵活的容器编排方案必然是捉襟见肘，水土不服。在此背景下，建设重庆农村商业银行新一代信用卡核心系统，将其平稳、有序、安全地改造、迁移并融入新一代科技支撑体系当中，成为了我们这次要打好的金融数字化转型攻坚战。这次的系统建设，有以下几个难点。

一是相比原系统有重大架构升级，代码调整广度和深度大。不但要承接好原有系统功能和服务，也要适应微服务架构，将服务逐个切分成互相解耦的独立服务，且切分后的服务编写方式要符合微服务平台的技术标准，满足迁移要求。

二是数据迁移难度大。首先，存量数据并非由行内系统产生和保存，为了将其迁移到分布式数据库架构，需要对应单个服务划分实体，做好访问规划和存储模式，因此对整体数据转换方案的可靠性和可行性有很高要求。其次，存量数据横跨多年，元数据经历过大量变动，版本历史复杂，难以追溯，必须做好一致性工作，保证所有存量数据能够表达一致的数据语义。此外，对于存量数据中的不规范和不准确问题，必须做好数据清洗和数据校验，随时识别和调整。

三是系统影响范围大。信用卡系统涉及各种渠道交易系统，同时和账务与清算体系联系紧密，不仅影响行内数据集市、智能决策、用户行为分析，也是征信、反洗钱等重要的外部监管体系的重要数据提供者。这就意味着海量的回归测试和数据验证工作。

图1  系统建设前后拓扑架构对比

建设目标

在新系统的拓扑结构及访问关系保持不变的前提下，达成如下建设目标。

1.性能要求

信用卡核心回迁后，系统性能设计不低于现有银行核心系统指标，设计目标为支持TPS大于300且TPS为300时，系统交易正确率不低于99%，系统平均响应时间不高于100ms。另系统支持1000万以上发卡量，且在1000万发卡量的情况下核心批量时间不超过2小时，总批量时间不超过4小时。

2.高可用架构

系统高可用建设以金融行业“两地三中心”高可用架构为目标，以如下几个方面作为架构设计原则：（1）RPO/RTO等级要求：以满足业务连续性为目标，基于灾备等级要求进行方案设计。（2）扩展性：兼顾与本地高可用、异地灾备的衔接性。（3）统一：基于主流、开放的基础设施，采用更通用的灾备技术。（4）便捷：降低方案实施的复杂度，提升灾备运维工作的便捷性。

基于以上原则，高可用架构设计如图2所示，其重点在于数据同步、请求切换环节：（1）数据同步零丢失。Oracle数据库DataGuard数据同步机制。数据库归档日志基于磁盘阵列技术的实时同步。（2）同城自动切换。基于DNS域名解析，生产本地不可用时，同城灾备中心接管请求。DNS域名服务器自身部署高可用集群，实现同城高可用。

图2  “两地三中心”高可用架构设计

3.保证数据迁移质量

为了将原有系统的数据无缝整合到新系统中，需要做到如下工作。一是统一数据传输标准。设计统一的数据交换规范，消除不同系统之间的数据壁垒，保证数据可复用，数据装载程序易于开发，同时保证数据的可靠性和完整性。二是完成数据影响及血缘分析。厘清数据谱系，对于每一条即将迁移到系统内的数据，知晓其来源和去向，进一步掌握数据生命周期。以此为基础，在数据验证过程中能够在字段级别准确把握测试验证范围，保证回归和验证工作不出现遗漏，规避隐患。三是识别并解决特殊数据的迁移问题。例如信用卡系统中存在部分与密钥相关的数据和参数数据，需要单独完善迁移和验证方案。

项目建设实践中的突出特点

1.软件研发敏捷化

由于核心类系统业务逻辑复杂，外围系统关联度高，我们在原有研发模式上引入了Scrum敏捷框架和精益思维，聚焦单个业务逻辑和业务场景，执行快速迭代开发。同时引入分支管理，持续集成，静态代码扫描，自动化测试等生产力工具，让每一次迭代以尽量小的人工代价完成持续交付。

2.质量管控一体化

坚持以项目代码质量为最重要的安全保障抓手，将其纳入研发体系。一方面引入自动化测试，静态代码扫描、代码评审会等机制，实现安全左移，尽早识别研发过程中产生的缺陷，减少隐患，缩减错误成本。另一方面，设计质量门禁，在DevOps平台支撑下，将其融入包含编译部署，验证打版等工作的统一流水线当中，通过二次开发将缺陷自动反馈给干系人，形成快速反馈的端到端的“微循环”模式。

3.数据验证常态化

项目建设的数据验证工作有两个重要含义：数据要从外部数据源迁移到本地，并且要融入自身系统的数据标准和数据规则；数据迁移到本地后，提供给下游系统（包含内部数据集市和外部监管报送等）使用的数据在逻辑、规模、标准上不能有任何变化，做到无缝迁移。通过实际经验总结，数据迁移中的问题通常具有隐蔽性、个别特殊性和历史复杂性。为了能够及时发现问题，必须要确立工作小组，制定详细计划，结合测试驱动开发（TDD）工程实践，将数据的验证工作常态化。在技术上，将每次遇到并解决的问题固化到迁移程序中；在工作流程上，遇到问题与数据产生方或使用方密切沟通，总结问题根源，形成新增的数据校验逻辑，持续增加到自动化的数据校验机制当中。

总结与展望

本项目的建设，一方面提高了企业科技能力的自主性和信息资产的透明度，另一方面也为将来全面推广数据治理和系统架构升级提供了一份良好的模版与案例。同时，在项目过程中沉淀下来的宝贵的实践经验，为敏捷开发、质量管理、数据管理等各项过程提炼出了易于落地、符合自身实际的企业执行标准。随着架构升级逐步全面深化，我们将以同类项目经验为指导，用“以战养战”的心态，继续朝着数字化转型迈出坚实的步伐。

（栏目编辑：韩维蜜）

推荐阅读

（点击图片查看精彩内容）

精彩内容回顾

（点击查看精彩内容）

新媒体中心：主任 / 邝源  编辑 / 傅甜甜  张珺  邰思琪